1. Field of the Invention
The present invention relates to software architectures, and more particularly, it relates to a method for describing software system architecture in terms of services at different abstraction levels.
2. Description of the Related Art
Software systems are generally made up of several different parts that interact with each other as required to perform a particular task. These different parts are referred to as parties or software (SW) artifacts that are generally designed together to make up the entire software architecture. The software architecture is formed with a hierarchy of SW artifacts that operate at different abstraction levels. The relationship between the system abstractions becomes an important factor when attempting to modify the software system to perform newly desired tasks.
Each modification made to an existing software system results in the evolution of that software system into a more complex system. This is particularly the case when taking into consideration the conceptual abstractions that make up the system, and is primarily due to the fact that modifications to an existing system are seldom such that they cleanly fit into the scope of the originally included abstractions. Instead, existing abstractions are often compromised or invalidated in order to facilitate new requirements to which the system is to be subjected. This results in potential downgrading or decreased dependability of the software system. In addition, the rework needed for correcting the abstractions may not be an option due to the time schedule for implementing the modifications and returning the product to market (i.e., time-to-market) or lack of development resources. Additional difficulties may arise due to the fact that sometimes fundamental abstractions need to be sacrificed even at the very beginning of software system development as a result of performance requirements which, for example, may lead to tightly coupled applications and poorly defined abstractions even in the early phases of a products life.
As the need for modifications, enhancements, or new features increases, the abstractions used as a basis for the software applications of the system usually become fragile. These abstractions are often augmented with extensions and exceptions that logically belong to the scope of some other abstraction(s), but due to the performance or resourcing reasons, need to be implemented as a special case of a certain abstraction. In addition, as different software artifacts that cooperatively constitute the system are maintained in parallel, the manner in which modifications are implemented and documented tends to diverge between the artifacts. This divergence does not help in the specification and implementation of new features, which typically requires interaction of artifacts and the abstractions included in them. Moreover, for large legacy systems, a serious dependability risk arises.
An alternative solution for the introduction of higher-level abstractions would be to use a layered architecture, with the top layers controlling lower layers. However, an introduction of such an architecture at this point in current day systems and scenarios would require massive rewriting of already verified and validated code as well as result in potentially unacceptable loss of performance. Therefore, centralized abstractions of distributed behaviors are adopted rather than incorporating everything into the physical structure of the software. The role of abstractions is then restricted to the facilitation of the modifications made in the actual code.